home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9704 / 000004_owner-urn-ietf _Wed Apr 2 14:57:10 1997.msg < prev    next >
Internet Message Format  |  1997-04-30  |  4KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id OAA25683
  3.     for urn-ietf-out; Wed, 2 Apr 1997 14:57:10 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA25676
  6.     for <urn-ietf@services.bunyip.com>; Wed, 2 Apr 1997 14:57:06 -0500 (EST)
  7. Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA20557  (mail destined for urn-ietf@services.bunyip.com); Wed, 2 Apr 97 14:57:04 -0500
  9. Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA07784; Wed, 2 Apr 1997 13:57:05 -0600 (CST)
  10. From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  11. Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA14954; Wed, 2 Apr 1997 13:57:00 -0600 (CST)
  12. Date: Wed, 2 Apr 1997 13:57:00 -0600 (CST)
  13. Message-Id: <199704021957.NAA14954@void.ncsa.uiuc.edu>
  14. To: "Ryan Moats" <jayhawk@ds.internic.net>
  15. Cc: urn-ietf@bunyip.com
  16. Subject: Re: [URN] urn: prefix is a brand name?
  17. In-Reply-To: <199703311929.NAA27474@newton.ncsa.uiuc.edu>
  18. References: <199703311929.NAA27474@newton.ncsa.uiuc.edu>
  19. Sender: owner-urn-ietf@Bunyip.Com
  20. Precedence: bulk
  21. Reply-To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  22. Errors-To: owner-urn-ietf@Bunyip.Com
  23.  
  24. Ryan Moats writes:
  25.  > Reasons that come to my mind for having "urn:" (I don't claim that anybody
  26.  > else needs to agree with these...):
  27.  
  28. So that's how it happened.  The previous time I had checked the
  29. syntax, the "urn:" was still optional, as I recall.  I don't recall
  30. any explicit statement to the mailing list that "we are now going to
  31. make 'urn:' required - any comments?".  Oh well, you wanted a brand
  32. name to protect, so you got it.
  33.  
  34.  > 1. URNs are NOT URLs.
  35.  
  36. Argument by affirmation, as Dan Connolly says.  Doesn't help.
  37.  
  38.  > 2.  As a corollary to #1, using the same space for URN NIDs and URL
  39.  > schemes leads to greater collisions than keeping the spaces separate.  
  40.  
  41. Even within URNs alone, or URLs alone, the same collisions could occur.
  42. But you are right that the space of both URNs and URLs is larger, and
  43. thus more collisions could occur.
  44.  
  45.  > 3. Currently (based on my interpretation of URL schemes, your mileage may
  46.  > vary), each and every URL scheme has a "resolution" "protocol" tied to it.
  47.  
  48. Not true.  There is an associated protocol for most URL schemes, but
  49. it is not necessarily used.  *If* you use the protocol, then you have
  50. protocol-specific info in the URL.  But if you do not use the
  51. protocol, then you still can use the same info.
  52.  
  53. E.g. web clients do, in fact, use things besides HTTP in resolving
  54. http URLs.  They are not prohibited from doing so.  It doesn't help
  55. to deny this.
  56.  
  57.  > The URN working group is proposing that initially there be a set of
  58.  > "resolution" "protocol(s)" for URNs tending toward a single
  59.  > resolution protocol.  All of these are independent of the URN NID.
  60.  
  61. Just to clarify, what you are calling "resolution protocols" are being
  62. called RDS protocols by other people, if I read you correctly.
  63.  
  64.  > Using "urn:" at the beginning of the URN provides a syntactic
  65.  > handle for browsers to recognize URNs as being distinct from URLs.
  66.  
  67. Not only are they made distinct from URLs, but all "urn:" ids can use
  68. the same RDS protocol.  I understand this perfectly fine; I just don't
  69. agree that it is necessary.
  70.  
  71.  > 3a. (#3 has the result that URN-aware browsers do not have to be
  72.  > modified if a new NID is defined as compared to what is required for
  73.  > supporting a new URL scheme.
  74.  
  75. Not true.  Browsers could resolve all current URL schemes as well as
  76. any new schemes using an RDS mechanism.
  77.  
  78. But new resolution mechanisms may be associated with any URL schemes
  79. AND any URN subschemes.  E.g. for "urn:hdl:" you might use the CNRI
  80. handle resolution mechanism directly.
  81.  
  82.  > An addition to the "family" of resolution
  83.  > protocols for URNs would require browser modification , but the direction
  84.  > is for less URN resolution protocols rather than more).
  85.  
  86. I agree, and that is why "urn:" would eventually become associated
  87. with a single protocol, just as most URL schemes are associated with a
  88. single protocol.
  89.  
  90. --
  91. Daniel LaLiberte (liberte@ncsa.uiuc.edu)
  92. National Center for Supercomputing Applications
  93. http://union.ncsa.uiuc.edu/~liberte/
  94.